\chapter{Analyse und Entwurf}


\section{Ziele und Anforderungen der Arbeit}	\label{sec:Ziele und Anforderungen der Arbeit}

Kernproblem der Aufgabenstellung ist die Synchronität zweier Messsysteme. Das heißt insbesondere, dass beide Systeme zum gleichen Zeitpunkt $t_0$ die Messung starten, die Messung zur gleichen Zeitbasis mit einem diskreten Zeitschritt von $dt_{ZB}$ durchführen\footnote{ein Vielfaches der Basis ist für beide Systeme zulässig.} und zur selben Zeit $t_f$ die Messung beenden, wobei das Beenden der Messung nicht unbedingt synchron erfolgen muss. Die Daten des Systems, welches über $t_f$ hinaus weitere Daten erhoben hat, können beim Zusammenführen der Datenpakete gelöscht werden. Das Starten und Beenden der Messung soll allerdings durch den Nutzer an einer einzigen Benutzerschnittstelle durchgeführt werden können. Des Weiteren kann eine Testfahrt bis zu acht Stunden dauern. Dies ist zu beachten, wenn es um die Datenmenge der erhobenen Daten sowie die Programmlaufzeit geht.

Die Synchronität, sowie die Bedienbarkeit an einer einzigen Stelle muss außerdem durch geeignete Tests nachgewiesen werden.

Eine einfache Erweiterbarkeit und Skalierbarkeit der entstandenen Softwaremodule, sowie deren unproblematische Integration in bestehende Software muss ebenfalls gewährleistet werden. So soll es beispielsweise problemlos möglich sein weitere analoge und digitale, direkt angeschlossene Sensorik, sowie seriell kommunizierende Messsysteme in die entstandene Softwareumgebung einzubinden. Besonderes Augenmerk soll außerdem auf die Integration in ein Datenbankverwaltungssystem gelegt werden. Dabei sollen die erhobenen Daten inklusive eines dazugehörigen Zeitstempels in einer \acf{SQL}-Datenbank abgelegt werden, so dass alle \acs{PiLoNav}-Projektpartner Zugriff auf die erhobenen Daten haben. Die Realisierung der Datenbank ist nicht Teil des Belegs, die Schnittstelle für eine solche Anbindung offen zu halten und zu dokumentieren, hingegen schon. 

An das Messsystem zur Aufnahme von terristrischen Sensordaten sollen unter anderem seriell kommunizierende Sensoren angeschlossen werden. Deren Auswertung hinsichtlich der Synchronität stellt ein größeres Problem dar als bei direkt angeschlossener Digital- oder Analogsensorik. Daher sollte zu Beginn der Arbeit ein Sensor der Firma u-blox mit dem System verbunden und ausgelesen werden. Dieser \acs{GPS}-Empfänger kann später als redundante Referenz für die gemessenen \acs{HF}-Rohdaten fungieren und soll später als Ausgangsumgebung für Synchronitätstest mit seriellen Sensoren dienen. 

% \subsection{Synchronität}	\label{sec:Synchronität}
% \subsection{Einfache Erweiterung}	\label{sec:Einfache Erweiterung}
% \subsection{Proof of Concept}	\label{sec:Proof of Concept}

\section{Aufbau der Testumgebung}	\label{sec:Aufbau der Testumgebung}

Der Hardwareaufbau des Systems besteht in erster Linie aus zwei \acs{PXI} Systemen. Das \acs{HF}-System dient zur Aufzeichnung und Wiedergabe von hochfrequenten Umfeldsignalen, während das \acs{NF}-System niederfrequente Multisensordaten verarbeitet. Zu diesen Sensoren gehören u.a. ein Mikrofon für akustische Untersuchungen der Messfahrt, ein Laser für eine exakte Abstandsbestimmung, eine Videokamera zur visuellen Zuordnung der erhobenen Daten, ein Intertialsensor zur Messung von Beschleunigungen und Drehraten, welcher über eine serielle Schnittstelle kommuniziert (auch \acf{IMU} genannt) sowie weitere serielle Sensorik, wie beispielsweise ein \acs{GPS}-Empfänger als redundante Referenz zu den erhobenen \acs{HF}s-Rohdaten. Beide \acs{PXI}-Systeme sind eigenständig laufende Industriecomputer, an denen Peripherie und Bildschirm angeschlossen werden können. 

Das \acs{HF}-System ist der \acs{URT} von Averna.
Am Institut gibt es ein PLAYBACK und ein RECORD System. Da am RECORD-System eine Triggerkarte fehlt und somit der Triggereingang für das Aufnehmen von Signalen nach Eintreffen eines Triggerereignisses nicht getestet werden kann, muss auf das PLAYBACK-System ausgewichen werden. \pdfmargincomment[style=todo]{Kann das URT nicht eigentlich selbst beide Richtungen? Oder benötigt es nur für die Aufnahme die Triggerkarte?} %TODO Kann das URT nicht eigentlich selbst beide Richtungen? Oder benötigt es nur für die Aufnahme die Triggerkarte?


Dies ist ein \acs{PXI}-System der Firma National Instruments mit proprietärer Software. Die erhobenen Daten werden auf das Festplattenarray NI HDD-8265, ebenfalls von National Instruments, mit einer Kapazität von ?? TB und einer kontinuierlichen Lese- und Schreibrate von 750 MB/s gespeichert. Die drei \acs{HF}-Kanäle am \acs{URT} werden mit einem Taktgenerator von Rubidium Normal auf 10\,MHz getaktet. Dieser Takt könnte ggf. für die globale Zeitbasis $dt_{ZB}$ verwendet werden, indem der letzte der vier Ausgänge des Taktgebers an einem Takteingang des \acf{NF}-Systems angeschlossen wird.  
Der \acs{URT} kann über Ethernet mittels der \acs{URT} \acf{API} (im folgenden remoteAPI genannt) ferngesteuert werden. Dabei können nahezu alle Einstellungen und Aktionen am \acs{URT} durchgeführt werden, die auch händisch vorgenommen werden können. \pdfmargincomment[style=todo]{Kapazität des HDD Arrays} %TODO Kapazität des HDD Arrays


Das \acs{NF}-System ist das frei, in \acs{LabVIEW} programmierbare, \acs{PXI}-System NI PXIe-8133 der Firma National Instruments im NI PXIe-1082 Chassis, wie in Abbildung~\ref{pic:PXI Chassis des NF-Systems} zu sehen. Zum Anschluss der unterschiedlichen Sensorik verschiedene \acs{PXI}-Karten im Chassis eingebaut, wie Tabelle~\ref{tab:Messkarten im NF-System} zeigt.

Die Auswahl der Messkarten im \acs{NF}-System ermöglicht unterschiedlichste Messaufgaben im \acf{RF}-Bereich und die Kommunikation mit mehreren seriellen Sensorsystemen und anderen Steuergeräten. Des Weiteren eignet sich das NI PXIe-6341 im Slot 13 sehr für gertiggerte Messungen der 16 Analog- und 24 Digitaleingänge und kann mit den vier Timern und Countern für das Erstellen und Zählen von Taktflanken verwendet werden.

\begin{figure}[htb]
	\centering
	\includegraphics[width=\linewidth]{img/NF-System}	%Breite und Pfad
	\caption{PXI Chassis des NF-Systems}		%Bildunterschrift
	\label{pic:PXI Chassis des NF-Systems}	%Referenz zum Verlinken
\end{figure}


\begin{table}
	\centering

	\begin{tabular}{|l|l|p{8cm}|}
	\hline
		\textbf{Position}	&	\textbf{Produktbez.}	&	\textbf{Anwendung} \\
	\hline
		Chassis		&	NI PXIe-1065	&	Gehäuse mit PXI-Bus in der Backplane \\
	\hline
		Controller	&	NI PXIe-8133	&	Windows 7-PC, Peripherieanschluss für Monitor, Maus und Tastatur \\
	\hline
		Slot 3		&	NI PXI-8430/8	&	acht RS232-Schnittstellen (bis zu 1 Mbit/s) \\
	\hline
		Slot 4		&	NI PXI-8430/8	&	acht RS232-Schnittstellen (bis zu 1 Mbit/s) \\
	\hline
		Slot 6		&	NI PXI-5652		&	\acs{RF}- und Mikrowellen-Signalgenerator \\
	\hline
		Slot 7		&	NI PXI-5601		&	\acs{RF}-Downconverter \\
	\hline
		Slot 8		&	NI PXIe-5622	&	Digitizer mit einer Abtastrate von 150 MS/s \\
	\hline
		Slot 9-11	&	HDD				&	Systemspeicher mit ?? GB Kapazität \\
	\hline
		Slot 13		&	NI PXIe-6341	&	DAQmx-basiertes Multifunktions-Datenerfassungsmodul \\
	\hline
		Slot 18		&	NI PXI-8431/8	&	acht RS485/RS422-Schnittstellen (bis zu 3 Mbit/s) \\
	\hline
		
	\end{tabular}

	\caption{Messkarten im NF-System}
	\label{tab:Messkarten im NF-System}
\end{table}

Im folgenden wird zur einfachen Verständlichkeit und besseren Lesbarkeit nur zwischen \acs{NF}-System und \acs{URT} unterschieden.

Als Vertreter der seriellen Messungen wird der \acs{GPS}-Controller LEA-6H der Firma u-blox aus der Produktreihe u-blox 6 GPS Moduls verwendet. Dieser soll in der realen Messfahrt nach einem Kaltstart Daten erheben. Dabei werden die Verbindung zu den zur Positionslösung notwendigen \acs{GPS}-Satelliten getrennt. Dadurch sind die Startbedingungen zu einer Messung immer gleich. Der LEA-6H kann seine Positionslösungen sowohl im NMEA 0183 Standard Protokoll, welches von der \acf{NMEA} definiert wurde, oder im proprietären UBX-Protokoll ausgeben.
 
Die Abbildung~\ref{pic:konzeptioneller Hardwareaufbau der Testumgebung} soll diesen Aufbau skizzieren und zeigt bereits konzeptionelle Ansätze zur Synchronität der beiden Systeme. So ist in der Abbildung auch das \acs{NF}-System mit dem 10~MHz Taktgeber verbunden, um auf das selbe $dt_{ZB}$ zurückzugreifen. Außerdem Wird das komplette System nur an einer Stelle durch den Nutzer gestartet, woraufhin beide Systeme mit der synchronen Datenerhebung beginnen. Dies lässt sich vermutlich am einfachsten realisieren, indem das \acs{NF}-System als Master betrieben wird und somit due Benutzeroberfläche des Messsystems enthält. Über die remoteAPI wird dann der \acs{URT} als Slave gestartet. 
Bei der Abbildung ist zu beachten, dass in der Darstellung die Erhebung der Daten, also der Datenfluss in RECORD-Richtung im Fokus steht.

In der Abbildung~\ref{pic:konzeptioneller Hardwareaufbau der Testumgebung} werden die Daten in der \emph{realen Welt} von den Sensoren erhoben und bei Ankunft an den \acs{PXI}-Geräten mit Zeitstempeln versehen. Beide Systeme schreiben ihre Daten auf eigene Datenspeicher. So verwendet der \acs{URT} ein Festplattenarray, während das \acs{NF}-System mit einer Datenbankapplikation kommuniziert. Diese läuft ebenfalls auf dem \acs{NF}-System. Beim Anschluss an den \acf{DB}-Server werden die Daten auf den Server geladen, so dass alle \acs{PiLoNav}-Projektpartner darauf Zugriff haben. Die \acs{HF}-Rohdaten verbleiben am Institut und werden nicht auf diesen Server gespeichert, da der Datenumfang zu hoch und der Nutzen für die Projektpartner nicht gegeben ist.

\begin{figure}[htb]
	\centering
	\includegraphics[width=\linewidth]{img/Hardware-Aufbau_und_Konzepte}	%Breite und Pfad
	\caption{konzeptioneller Hardwareaufbau der Testumgebung}		%Bildunterschrift
	\label{pic:konzeptioneller Hardwareaufbau der Testumgebung}	%Referenz zum Verlinken
\end{figure}

\section{Softwareentwurf}	\label{sec:Softwareentwurf}
Abstrakt betrachtet kann die Aufgabenstellung in mehrere Unterprojekte aufgeteilt werden. Für alle Softwaremodule muss jedoch die einfache Erweiterung und Skalierbarkeit gewährleistet sein. 
% Zunächst die Kommunikation mit dem u-blox-Empfänger, sowie die Darstellung und Speicherung der empfangenen Sensordaten. Als nächstes gilt es eine gemeinsame Zeitbasis $dt_{ZB}$ für die beiden Messsysteme zu installieren. Außerdem muss der synchrone Start der Systeme gewährleistet werden.	%TODO sollte doch eig. bei Ziele und Anforderungen stehen und nicht bei HW Aufbau

% \begin{itemize}
%   \item Kommunikation mit dem u-blox Empfänger
%   \item globale Zeitbasis $dt{ZB}$
%   \item synchroner Startzeitpunkt $t_0$
% \end{itemize}

\begin{description}
  \item[u-blox Empfänger Kommunikation] über die serielle Schnittstelle inklusive der Betrachtung der Zeitstempelverarbeitung beim Empfang einer Nachricht
  \item[globale Zeitbasis $\bf dt_{ZB}$]als systemübergreifenden Grundtakt für die Datenerhebung, so dass mehrere \acs{PXI}-Systeme zeitgleich über die Dauer einer bis zu achtstündigen Messfahrt Daten synchronisiert erfassen.
  Des Weiteren soll ein Konzept für einen globalen Zeitstempel für alle erhobenen Daten, die nach der Erhebung auf die Datenbank gespeichert werden sollen, erarbeitet werden. 
  \item[synchroner Start- und Endzeitpunkt $\bf t_0$ und $\bf t_f$] als absolut synchroner Beginn der Messung und somit erster Messpunkt für beide Systeme, bzw. synchrones Ende der Gesamtmessung. Letzteres unterliegt keinen Echtzeitkriterien.
\end{description}

\subsection{Referenzdesign als Ausgangsentwurf für die Unterprojekte}	\label{sec:Referenzdesign für die Unterprojekte}

Die vorgestellten Unterprojekte werden nach dem Vorbild des auf der VIP~2012 vorgestellten Referenzdesigns für einen Batterieprüfstand \cite{vip12} erstellt.
In dieser Designvorlage wird im allgemeinen zwischen einer Initialiserungs-, einer Iterations- und einer Terminierungsphase unterschieden, wie in Abbildung~\ref{pic:MAIN.VI des Referenzdesigns} zu sehen. Innerhalb der Iterationsphase werden mehrere Programmabschnitte parallel ausgeführt.

\begin{figure}[htb]
	\centering
	\includegraphics[width=0.7\linewidth]{img/RefDes_main}	%Breite und Pfad
	\caption{\texttt{MAIN.VI} des Referenzdesigns}		%Bildunterschrift
	\label{pic:MAIN.VI des Referenzdesigns}	%Referenz zum Verlinken
\end{figure}

\begin{description}
  \item[\texttt{\textbf{DataAcquisition.vi}}] entnimmt die Daten aus der Umgebung auf und schreibt sie in die \texttt{DAQ-Queue} (ein gepufferter \acf{FIFO}-Speicher). Diese Datenerhebung muss an die Art des Sensors angepasst werden und wird ggf. in einer bestimmten Frequenz getaktet.
  \item[\texttt{\textbf{CONTROL.vi}}] verarbeitet die Daten aus der \texttt{DAQ-Queue} und schreibt die verarbeiteten, ggf. mit weiteren Informationen angereicherten Daten, in die \texttt{LOGGING-Queue} und den \texttt{VIEW-Notifier} (ein ungepufferter Speicher).
  \item[\texttt{\textbf{Logging.vi}}] schreibt alle erhobenen Daten in eine Datei, bzw. kann als Anbindung für andere Datenverwaltungssysteme (bspw. eine \acs{SQL}-\acs{DB}) genutzt werden.
  \item[\texttt{\textbf{VIEW.vi}}] ist die Benutzerschnittstelle für die Visualisierung der Daten zur Laufzeit und Interaktion mit dem Anwender.
\end{description}

Die bewährte, modulare Struktur des Referenzdesigns hilft bei der Erweiterung und Änderung der einzelnen Softwareteile. So kann beispielsweise leicht auf das Verwenden einer Datenbank anstelle von Messdateien umgestiegen werden, ohne am Messvorgang oder der Nutzerschnittstelle Änderungen vornehmen zu müssen. Auch die Geschwindigkeit der Datenspeicherung kann reguliert werden, es muss nicht bei jedem Eingang eines neuen Datums in die \texttt{LOGGING-Queue} sofort gespeichert werden, es kann auf eine bestimmte Anzahl von Messdaten, oder erst nach Ablauf einer bestimmten Zeit gespeichert werden. Dies ist unter Umständen notwendig, da die Datei-I/O mitunter der langsamste Vorgang an einem Messsystem sein kann.

Aufgrund der gepufferten Übertragung der Sensorwerte sind die geschaffenen Datenschnittstellen außerdem sehr robust gegenüber äußeren, nichtdeterministischen Einflüssen, die auf Echtzeit-fernen Betriebssystemen, wie Windows 7, auftreten können. 

Eine Besonderheit des Referenzdesigns ist es, dass jedes Top-Level-\acs{VI} und auch fast jedes \acs{SubVI} darunter, mit einem Referenzcluster als Ein- und Ausgang ausgestattet ist. Dieser enthält alle Referenzen und global notwendigen Parameter und ist als Typdefinition hinterlegt. Wird also in einer unteren Ebene der \acp{VI} ein weiterer Wert, also ein weitere Eingang benötigt, muss nur die Typdefinition erweitert werden und alle mit der Typdefinition verbundenen \acp{VI} aktualisieren sich automatisch. Auf diese Weise kann später beispielsweise leicht ein weiterer serieller Sensor oder Aktor hinzugefügt, oder ausgetauscht werden, indem einfach eine weitere Referenz im Referenzcluster hinterlegt, oder die existierende geändert wird.

Zur Erleichterung der Handhabung der Projektdateien ist das Projekt am \acf{MVC} Paradigma (nach \cite[209]{tinf}) angelehnt. Dabei werden alle Typendefinitionen und Konvertierungs-\acp{VI} im Ordner \texttt{Typedef} gespeichert, was dem Model-Teil des \acs{MVC}-Konzepts entspricht.
Alle \acp{SubVI} sind in Ordnern des übergeodneten VIs aus der Iterationsphase abgelegt und werden in weitere Unterordner sortiert, sobald ihre Anzahl zehn überschreitet, oder es sich aufgrund ihrer Zusammengehörigkeit anbietet. 

Das Referenzdesign hat sich in der Praxis bei mittleren und großen Projekten sehr bewährt und wird daher für die infolge realisierten Unterprojekte als Ausgangsbasis genutzt.

\subsection{Verwendung eines u-blox-Empfängers zur Realisierung eines Machbarkeitsnachweises für die serielle Sensordatenextraktion}	\label{sec:Verwendung des u-blox-Empfängers zur Realisierung des Proof of Concepts für die serielle Sensordatenextraktion}

Der LEA-6H kann direkt über einen \acf{COM}-Port, oder über einen im Controller verbauten \acf{USB}-Seriellwandler an das \acs{NF}-System angeschlossen werden. Beide Konstellationen verwenden/installieren den Empfänger als \acs{COM}-Port im Windows Gerätemanager. Über Tools wie HTerm kann sofort mit dem Empfänger kommuniziert werden und die Funktionsfähigkeit des Empfängers nachgewiesen werden. In LabVIEW wird die \acf{VISA} zur Kommunikation verwendet. Der \acs{VISA}-Standard ist eine Systemferne \acs{API} zum Aufrufen systemnaher Treiber und stellt eine einheitliche Programmierumgebung für unterschiedliche Kommmunikatinosprotokolle dar. Der Programmierer muss die Schnittstelle also nicht auf Treiber oder Hardwareebene umsetzen, sondern kann direkt die \acs{VISA}-Umgebung verwenden.


\subsubsection{NMEA-Daten über serielle Schnittstelle auslesen}	\label{sec:NMEA-Daten über serielle Schnittstelle auslesen}
Der LEA-6H ist so konfiguriert, dass Positionslösungen mit 1~Hz im \acs{NMEA} Protokoll über alle Schnittstellen gesendet werden. Die Standardkonfiguration der seriellen Schnittstelle des LEA-6H zeigt Tabelle~\ref{tab:Standardkonfiguration der seriellen Schnittstelle des LEA-6H}.


Der Aufbau des \acs{NMEA}-Protokolls ist in Abbildung~\ref{pic:NMEA Protokoll Frame} verdeutlicht. Eine \acs{NMEA}-Nachricht beginnt immer mit einem \$-Zeichen. Darauf folgt ein Adressbezeichner, der Art und Format der kommenden Nachricht angibt. Der Inhalt der Nachricht kann eine beliebige Länge besitzen und besteht meist aus mehreren Datenfeldern, die mit Kommata getrennt sind. Abgeschlossen wird die \acs{NMEA}-Nachricht mit einer zwei Byte Prüfsumme sowie den \acf{ASCII}-Zeichen für Wagenrücklauf \texttt{<CR>} und Zeilenvorschub \texttt{<LF>}. 

\begin{table}
	\centering

	\begin{tabular}{|c|c|}
		\hline
		Baudrate & 9600 bps\\
		\hline
		Stoppbit & 1.0\\
		\hline
		Paritätsbit & keins\\
		\hline
	\end{tabular}

	\caption{Standardkonfiguration der seriellen Schnittstelle des LEA-6H nach \cite[S.~7]{ubx6}}
	\label{tab:Standardkonfiguration der seriellen Schnittstelle des LEA-6H}
\end{table}

Die ermittelte Positionslösung wird über eine Standard-\acs{GPS} Nachricht mit der Adresse \texttt{GPRMC} vom LEA-6H gesendet. Wie in Abbildung~\ref{pic:NMEA Protokoll Frame} zu sehen ist, steht das \texttt{GP} für \acs{GPS}-Receiver. Das \texttt{RMC} ist die Abkürzung für \textit{Recommended Minimum Data}. Diese \acs{NMEA}-Nachricht enthält die aktuelle \acs{GPS}-Zeit und die Position in Längen und Breitengrad. Auf den Aufbau und die Verwendung dieser Nachricht wird im Abschnitt \ref{sec:Kommunikation mit u-blox Empfänger} näher eingegangen. \pdfmargincomment[style=todo]{Überprüfen ob Referenz stimmt und ob darauf eingegangen wird} %TODO Überprüfen ob Referenz stimmt und ob darauf eingegangen wird


\begin{figure}[htb]
	\centering
	\includegraphics[width=\linewidth]{img/nmea-protocol-frame}	%Breite und Pfad
	\caption{NMEA Protocol Frame aus \cite[S.~49]{ubx6}}		
	\label{pic:NMEA Protokoll Frame}	%Referenz zum Verlinken
\end{figure}

\subsubsection{Empfangene Daten speichern}	\label{sec:Empfangene Daten speichern} 

Zur Bearbeitungszeit des Belegs ist die Anbindung an die \acs{SQL}-Datenbank noch nicht umgesetzt. Daher sollen die erhobenen Daten innerhalb des \texttt{LOGGING.VI}s aus der \texttt{LOGGING-Queue} entnommen und zunächst in eine \acf{TDMS}-Datei\footnote{Ein offenes und unter \cite{tdms} standardisiertes Dateiformat für Messdaten} gespeichert werden. Mit der Queue als Schnittstelle ist es später leicht möglich auf eine andere Form der Sensordatenverwaltung auszuweichen und beispielsweise die Datenbankanbindung einzubetten. Die temporäre Umsetzung der Datenspeicherung in eine \acs{TDMS}-Datei unterliegt somit keinen besonderen Anforderungen. \pdfmargincomment[style=todo]{Anhand des VIs von Andre zeigen, dass das prinzipiell jetzt schon möglich ist! Aber das dann im Ausblick zeigen} %TODO Anhand des VIs von Andre zeigen, dass das prinzipiell jetzt schon möglich ist! Aber das dann im Ausblick zeigen


\subsubsection{Initiierung des Kaltstarts mithilfe des UBX-Protokolls}	\label{sec:Initiierung des Kaltstarts mithilfe des UBX-Protokolls}
Da ein \acs{GPS}-Empfänger wie der LEA-6H immer mehrere Satelliten für die Positionslösung benötigt und das Suchen dieser Satelliten mitunter viel Zeit in Anspruch nimmt, speichert der Empfänger Informationen zu den Satelliten, mit denen er als letztes verbunden war, um sich schneller wieder mit diesen verbinden zu können. Da der Empfänger zwischen zwei realen Messfahrten allerdings meistens eine große Zeit- und Positionsänderung erfährt, sind die gespeicherten Informationen zu den \acs{GPS}-Satelliten oft hinfällig, so dass ein Hardware-Reset eine optimale und standardisierte Ausgangssituation für eine Messfahrt darstellt.
Des Weiteren beginnt eine Messfahrt immer mit einer circa zehn minütigen Standmessung, um einen definierten Startn für die spätere Datenanalyse zu generieren, was ebenfalls für einen Hardware-Reset spricht.

Um einen solchen Hardware-Reset zu initiieren kann die in \cite[S.~16 f.]{ubx6} beschriebene Konfigurationsnachricht \texttt{UBX-CFG-RST} für den \texttt{cold start} verwendet werden. Diese Nachricht wird über den selben \acs{COM}-Port gesendet, über den auch die \acs{NMEA} Daten empfangen werden. Dafür ist allerdings die Implementierung des in \cite[S.~82 ff.]{ubx6} definierten proprietären UBX-Protokolls notwendig.

Abbildung~\ref{pic:UBX protocol frame} zeigt den Aufbau des UBX-Protokolls. Die ersten beiden Zeichen dienen als Kennzeichnung des Starts einer UBX-Nachricht und sind somit immer gleich. Klasse und \acf{ID} für die Konfigurationsnachricht \texttt{UBX-CFG-RST} sind \texttt{0x06} und \texttt{0x04}, wie in \cite[S.~138 f.]{ubx6} nachzulesen. Die Länge der Nachricht, bzw. die variierende Größe der Nutzdaten (\textit{Payload}) wird in einem zwei Byte großen Feld hinterlegt. Um einen Kaltstart durchzuführen muss der Payload \texttt{0x0000ffff} entsprechen. Zur Berechnung der Checksumme und dem Auswerten der Bestätigungs-Nachricht, die auf jede Konfigurationsnachricht folgt, sollten einmalig \acp{VI} hinterlegt werden. Auf die Umsetzung des UBX-Protokolls wird in Abschnitt~\ref{sec:Kommunikation mit u-blox Empfänger} eingegangen. Die komplette Nachricht nach UBX-Protokoll für den Kaltstart ist in Tabelle~\ref{tab:UBX-CFG-RST Nachricht für Kaltstart} zu sehen.


\begin{figure}[htb]
	\centering
	\includegraphics[width=\linewidth]{img/ubx-protocol-frame}	%Breite und Pfad
	\caption{UBX Protocol Frame aus \cite[S.~82]{ubx6}}		%Bildunterschrift
	\label{pic:UBX protocol frame}	%Referenz zum Verlinken
\end{figure}


\begin{table}

	\centering
	\begin{tabular}{|l|p{1cm}|p{1cm}|p{1cm}|p{1cm}|l|l|p{1cm}|p{1cm}|}
	
	\hline
	\textbf{MSG} & \textbf{SC\_1} & \textbf{SC\_2} & \textbf{CLASS} & \textbf{ID} & \textbf{LENGTH} & \textbf{PAYLOAD} & \textbf{CH\_A} & \textbf{CH\_B} \\
	\hline
	Kaltstart & \texttt{0xB5} & \texttt{0x62} & \texttt{0x06} & \texttt{0x04} & \texttt{0x0400} &\texttt{0x0000ffff} &\texttt{0x0C} & \texttt{0x61} \\
	\hline	
	\end{tabular}

	\caption{\texttt{UBX-CFG-RST} Nachricht für Kaltstart}
	\label{tab:UBX-CFG-RST Nachricht für Kaltstart}
\end{table}

Nach dem Kaltstart werden, je nach Empfänger über einen Zeitraum von 30 - 600~s invalide Positionslösungen ermittelt, welche bei Ausgabe im \acs{NMEA}-Protokoll auch als solche gekennzeichnet werden. \cite[S.~51]{ubx6} Diese invaliden Daten sind für eine spätere Analyse nicht uninteressant und sollen daher ebenfalls erhoben und gespeichert werden.
Der Messvorgang, bzw. der Übergang in die Iterationsphase (siehe Abbildung~\ref{pic:MAIN.VI des Referenzdesigns}) kann also sofort nach der Initiierung des Kaltstarts, welcher somit Teil der Initialisierungsphase ist, beginnen.
 Beim \acs{DB}-Verfahren werden die empfangene Strings komplett abgespeichert, so dass die Information über die Validität der Positionslösung nicht verloren geht. Dies ist bei der temporären Implementierung des \texttt{LOGGING.VI} nicht der Fall, was für den Machbarkeitsnachweis für die Kommunikation mit dem LEA-6H allerdings unerheblich ist. 

% \subsubsection{Anwendung des Referenzdesigns}	\label{sec:Anwendung des Referenzdesigns}
% \pdfmargincomment[style=todo]{Kein CONTROL in Implementierung kurz nennen} %TODO Kein CONTROL in Implementierung kurz nennen

%  
%  
%  - Kaltstart in init
%  
%  
%  - (beispielhaft) öffnen und schließen der VISA-Schnittstelle
\subsection{Realisierung der Synchronität}	\label{sec:Realisierung der Synchronität}


Angelehnt am \acs{LabVIEW}-Datentyp \textit{Waveform} wird für die eineindeutige Zuordnung von Zeitstempel zu Datenpunkt bei einer festen Frequenz der Erhebung von Datensätzen nur ein Startzeitpunkt $t_0$ und eine Periode $dt$ benötigt um bei einem Array aus zeitdiskreten Datenpunkten den Zeitstempel des Datenpunkts $n$ zu ermitteln \cite[S. 132]{LVE}. Dies wird später auch in Gleichung~\ref{eq:verstrichene Zeit delta t} gezeigt.

Dementsprechend muss für eine synchrone Datenerhebung über mehrere Systeme hinweg nur der synchrone Start der Messung und die Bereitstellung einer globalen Zeitbasis gewährleistet werden.


\subsubsection{Synchroner Startzeitpunkt}	\label{sec:Synchroner Startzeitpunkt}
Um beide Systeme synchron starten zu lassen, muss zunächst festgelegt werden, was als "`synchron"' bezeichnet werden darf. 
Als diskretes Zeitfenster für die Echtzeitkriterien sind 4~ms vorgegeben. Dementsprechend sind die erhobenen Daten als \emph{synchron} anzusehen und mit dem selben Zeitstempel zu versehen, sobald ihre Ankunft am Messsystem 4~ms nicht überschreitet. Da diese Zeitspanne einer Frequenz von 250~kHz entspricht und die Messdaten am \acs{URT} im GHz-Bereich aufgenommen werden, reicht diese grobe Auflösung nicht aus, um sie für die globale Zeitbasis $dt_{ZB}$ zu verwenden. Allerdings können die 4~ms als die maximal zulässige Abweichung $\Delta t_0$ der Startzeitpunkte der beiden Systeme angenommen werden.

\begin{equation}
	\Delta t_0 = \left| t_0^{URT} - t_0^{NF} \right| \leq 4 ms
	\label{eq:deltat0}
\end{equation}

Über den Triggereingang am \acs{URT} kann das System auf die Freigabe, ähnlich einer Master-Slave-Architektur, des \acs{NF}-Systems warten. Dabei ist zu beachten, dass beide Systeme zunächst hochfahren müssen. Bezugnehmend auf Abbildung~\ref{pic:MAIN.VI des Referenzdesigns}, wird zwischen der Initialisierungsphase und der Iterationsphase eine Triggerphase eingefügt. In dieser Phase warten beide Systeme auf das Ereignis einer (ggf. externen) Triggerquelle und starten somit synchron in die Iterationsphase. Diese Idee entstand angelehnt an das \acs{LabVIEW}-Synchronisierungsverfahren \textit{Rendezvous} (vgl. \cite[S.~255 f.]{LVE}) und ist konzeptionell in Abbildung~\ref{pic:Kommunikationskonzept der Triggerphase} verdeutlicht.
Bei diesem Konzept ist davon auszugehen, dass beide Systeme in der Triggerphase komplett initialisiert sind und eine minimale Zeit bis zum Start der Messung benötigen. Die Zeit, die vom Senden des Triggersignals bis zum Start des jeweiligen Systems vergeht ist als $t_0^{URT}$ bzw. $t_0^{NF}$ definiert. Der Sendezeitpunkt des Triggersignals ist folglich $t=0$, so dass auch die seit Beginn der Messung verstrichene Zeit $\Delta t=0$ sein muss, da bisher $n=0$ Messungen mit einer Periode von $dt_{ZB}$ ausgeführt wurden.


\begin{equation}
	\Delta t = n \cdot dt_{ZB}
	\label{eq:verstrichene Zeit delta t}
\end{equation}



\begin{figure}[htb]
	\centering
	\includegraphics[width=\linewidth, page=2]{img/Kommunikations-Konzept}	%Breite und Pfad
	\caption{Kommunikationskonzept der Triggerphase}		%Bildunterschrift
	\label{pic:Kommunikationskonzept der Triggerphase}	%Referenz zum Verlinken
	\pdfmargincomment[style=fixme]{Das ist nur eine Skizze, muss überarbeitet und kleiner gemacht werden!} %FIXME Das ist nur eine Skizze, muss überarbeitet und kleiner gemacht werden!
\end{figure} 



\subsubsection{Synchrone Zeitstempel während der Messung}	\label{sec:Synchrone Zeitstempel während der Messung}
Die Synchronitätsanforderungen der globalen Zeitbasis leiten sich aus der höchsten Abtastrate der am \acs{NF}-System verwendeten Sensorik ab. Das Mikrofon nimmt mit einer Abtastrate von 44~kHz Umgebungsdaten auf. Dies entspricht einer Periode von ca. 22,727~ns. Nach dem Nyquist-Shannon-Abtasttheorem kann eine systemübergreifende Zuordnung der erhobenen Daten nur realisiert werden, sofern die globale Zeitbasis $dt_{ZB}$ kleiner als  $11,363~\mu s$ ist. (vgl. \cite[S.~657]{tinf}) \pdfmargincomment[style=todo]{ist das korrekt? gibt es was schnelleres? Die IMU übermittelt ja nur Bytes mit 125 kHz, nicht gemessene Daten} %TODO ist das korrekt? gibt es was schnelleres? Die IMU übermittelt ja nur Bytes mit 125 kHz, nicht gemessene Daten

\begin{equation}
	dt_{ZB} < \frac{1}{2}dt_{mic}=11,363~\mu s
	\label{eq:dtZBMAX}
\end{equation}

Da das \acs{URT} seine Messkanäle über die 10~MHz Rubidiumnormal Taktquelle synchronisiert, bietet es sich an die selbe Quelle auch für das \acs{NF}-System zu verwenden. Diese Konstellation birgt allerdings das Problem, dass die Taktquelle ununterbrochen läuft. Um eine korrekte Zuordnung der Datenpunkte am \acs{NF}-System zu gewährleisten, muss klar sein, welche Taktflanke die \emph{erste} ist, also wenn $n=0$. Bei einem 10~MHz Takt, der ununterbrochen bereits in der Initialisierungs- und Triggerphase läuft, muss das Flankenzählen am \acs{NF}-System zum Start der Messung resettet werden. Dies müsste dann innerhalb von $10~\mu s$ geschehen. \pdfmargincomment[style=todo]{sollte eig. kein Problem sein . . . Gab es nicht das Problem, dass alle Ausgänge am Rubidiumnormal vergeben waren??} %TODO sollte eig. kein Problem sein\ldots
Einfacher ist es, am \acs{NF}-System einen Takt über die \pdfmargincomment[style=fixme]{welche PXI Karte??} %FIXME welche PXI Karte??
zu erzeugen und die erstellten Flanken selbst zu zählen. \pdfmargincomment[style=todo]{ppm der Karte und des Rubidiumnormal gegenüberstellen und zeigen, dass es keine Syncprobleme gibt. Hatte ich doch mal irgendwo ausgerechnet . . . !!} %TODO ppm der Karte und des Rubidiumnormal gegenüberstellen und zeigen, dass es keine Syncprobleme gibt. Hatte ich doch mal irgendwo ausgerechnet . . . !!
Dieser selbst erzeugte Takt kann dann ebenfalls als Triggerereignis für das \acs{URT} verwendet werden, so dass die erste gesendete Flanke tatsächlich die 0-te Flanke ist. Nun muss nur sichergestellt werden, dass am \acs{NF}-System erst die Flankenzählung läuft und danach die Flankengenerierung gestartet wird.  